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BATCH PROVING AND PROOF SCRIPTING IN PVS 


Cesar A. Munoz* 


ABSTRACT 

The batch execution modes of PVS are powerful, but highly technical, features of 
the system that are mostly accessible to expert users. This paper presents a PVS 
tool, called ProofLite, that extends the theorem prover interface with a batch proving 
utility and a proof scripting notation. ProofLite enables a semi-literate proving style 
where specification and proof scripts reside in the same file. The goal of ProofLite is 
to provide batch proving and proof scripting capabilities to regular, non-expert, users 
of PVS. 

1 INTRODUCTION 

The Prototype Verification System (PVS) [9] is a higher order logic theorem prover developed 
and maintained by SRI International. 1 PVS has been applied to verification problems in a 
variety of areas, including safety critical industrial applications. 

PVS is well known for its expressive specification language and its impressive theorem 
prover. The specification language is based on a rich type system that supports predicate sub- 
typing and dependent records [12]. The theorem prover has been optimized for large proofs, 
for example basic numerical types are built-in and propositional simplification uses Binary 
Decision Diagrams. Furthermore, like most theorem provers, PVS can be conservatively 
extended with user-defined inference rules [10], called strategies, that tailor the deductive 
power of the system to specific domains [1, 15]. 

Less known features of PVS are the batch execution modes. Although these modes 
are quite powerful, their correct use requires a good knowledge of the PVS programming 
interface. Therefore, they are mostly accessible to PVS expert users. 

Another limitation of the PVS interface is that, in contrast to most theorem provers, 
it does not explicitly support a proof scripting notation where proofs are written in a non- 
interactive way. In PVS, proofs are interactively constructed via proof commands through a 
read-and-evaluate loop. The proof commands are automatically saved by the system in text 
files using an internal format. Those files are not intended to be directly edited by the user. 

These two capabilities, batch proving and proof scripting, become important when PVS 
is integrated into other verification tools. Assume for example that a static checker of a 
programming language wants to generate proof obligations for PVS along with specialized 
proof commands for each obligation. The formulas can be written into a .pvs file. The 
proofs commands, on the other hand, have to be written into a . prf file using the internal 
proof fornat. Finally, a PVS batch execution mode has to be used to check whether the proof 
obligations are discharged or not. 

*This work was supported by the National Aeronautics and Space Administration, Langley Research 
Center under the Research Cooperative Agreement No. NCC- 1-02043. 

'National Institute of Aerospace (NIA), 100 Exploration Way, Hampton VA, 23666. Email: munozO 
nianet . org. 

1 PVS is electronically available from http : //pvs . csl . sri . com. 
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This paper describes a PVS tool, called ProofLite, that provides a user-friendly interface 
to a PVS batch execution mode. ProofLite also supports a proof scripting notation where 
formulas and proofs may reside in the same text file. The rest of this paper is structured 
as follows. Section 2 gives an overview of the PVS batch modes. Section 3 briefly presents 
different proof formats used by PVS. Sections 4 and 5 describe the tool and its applications. 
The last section concludes this work. 

2 PVS BATCH MODES 

Typically, users interact with PVS through its customized Ernacs interface. Even mechanical 
tasks that do not involve editing, such as, rerunning all the proofs of a fully developed theory, 
normally require an interaction with the PVS Emacs interface. 

Curious PVS users may have noticed that the PVS command line accepts the option 
“-batch'’, which runs the system in batch mode [11]. This option is generally used with the 
option -1 that loads and executes an Emacs Lisp file. This facility is extremely powerful as 
arbitrarily complex Emacs Lisp can be executed this way. In particular, any PVS command 
can be invoked. Unfortunately, many PVS commands are context-dependent and only make 
sense when they are invoked interactively. Therefore, the correct use of this mechanism 
requires a good knowledge of the PVS programming interface. 

One of the main uses of the PVS batch mode is regression testing. For instance, the fol- 
lowing Emacs Lisp code will change the context to <dir>, rerun all the proofs of <f ile ,pvs>, 
and collect the output into <f ile . log>. It will then compare the output against the last run 
and report whether there is nothing to compare, there are no significant changes, or some 
difference were found since the last run. 

(pvs-validate 
"<f ile . log>" 

"<dir>" 

(let ( (current-pref ix-arg t)) 

(prove-pvs-f ile <f ile ,pvs>) ) ) 

If this code is saved in the file <file.el>, the validation run can be performed in batch 
mode with the command line: 

7. pvs -batch -1 <file.el> 

When a difference is reported, the Emacs command 

M-x pvs-compare-validation-window will place the cursor at the position where the output 
files differs, if the two log files are in a split window. 

For real PVS hackers, a more obscure execution mode is available through the option 
-raw. In this mode, the PVS Common Lisp runtime engine is executed without the Emacs 
interface. Common Lisp expressions, and in particular PVS Common Lisp commands, can 
be executed in batch mode via the command line option -e. 

3 PVS PROOF FORMATS 

In PVS, specifications and proofs reside in different types of files. Specifications are written in 
. pvs text files. Proofs are interactively constructed via proof commands and automatically 
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saved by the system in .prf files. Although proof hies are also text hies, they are not 
intended for user manipulation. The format of the . prf hie is described by Sam Owre, one 
the main developers of the system, in a message to the PVS mailing list on June 2003 as 
follows: “. . . The format is: 

(<theory-id> 

(<decl-id> 

<def ault-proof-posn> 

(<id> 

<description> 

<create-date> 

<run-date> 

<script> 

<status> 

<ref ers-to> 

<real-time> 

<run-time> 

<interactive?> 

<decision-procedure-used>) 

. . .) 

where <def ault-proof-posn> is the (0-based) position of the default proof in the list of 
proofs associated with the declaration. The <create-date> is the time that the proof 
was hrst saved, and the <run-date> is the time it was last rerun. The <real-time> and 
<run-time> are the time it took the last time it was run, and <interactive?> indicates 
whether that was an interactive run or not. These may not really rehect the last run, because 
the prove-theory, etc. commands do not write out a new . prf hie. Most of the rest of the 
holds should be self-explanatory ...” 

Furthermore, existing PVS proofs can be edited using the PVS Ernacs interface. When 
a proof is edited by the user, it is presented in the Emacs buffer Proof as a sequence of 
commands in a proof tree. For instance, a possible proof of lemma th2 : 

th2 : LEMMA a <= b IMPLIES a*abs(a) <= b*abs(b) 

is displayed in the buffer Proof as follows: 

^ II II 

(skeep) 

(case "a >= 0") 

(("1" (grind :theories "real_props") ) 

(" 2 " 

(grind :theories "real_props") 

(mult-ineq -1 -1 : signs (- -)) 

(assert) ) ) ) 
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Note that, in this format, any control structure provided by a proof strategy such as try, 
if, branch, etc., is lost. 

The buffer Proof is typically used for global editing operations, such as replacing an 
identifier, for copying a proof from one formula to another, and for stepping through a proof 
via the interactive theorem prover. However, given the lack of control structure information, 
the proof format displayed in the buffer Proof is not suitable for proof scripting. 

4 PROOFLITE 

ProofLite is a PVS package . 2 PVS packages, which are also called prelude extensions, are 
the mechanism offered by PVS to modularly and conservatively extend the system with 
user-defined Ernacs Lisp code, Common Lisp code, proof strategies, and PVS theories. In 
particular, the ProofLite package consists of Ernacs Lisp and Common Lisp functions that 
implement: 

• a command line utility, called prove it, 

• a proof scripting notation, and 

• a set of Ernacs commands for management of proof scripts. 

4.1 The proveit Utility 

ProofLite includes the command line utility proveit that executes the theorem prover in 
batch mode on a . pvs hie and reruns all its proofs. 

For instance, assume that all the formulas in thms.pvs have been proved. 


thms : THEORY 
BEGIN 

a,b : VAR real 
nza : VAR nzreal 


thl 

LEMMA a* a >= 

th2 

LEMMA a <= b 

th3 

LEMMA a* a >= 

th4 

LEMMA (nza/2) 

th3a 

LEMMA a* a >= 

th4a 

LEMMA (nza/2) 

th_5_6 

LEMMA EXISTS 

th_6_7 

LEMMA EXISTS 

th_8 

LEMMA EXISTS 

th_9 

LEMMA EXISTS 

END thms 



0 

IMPLIES a*abs(a) <= b*abs(b) 
0 

*(2/nza) = 1 
0 

*(2/nza) = 1 
(a) : 5 < a AND a < 6 
(a) : 6 < a AND a < 7 
(a,b) : a+b = 8 
(a,b) : a+b = 9 


The invocation 
y„ proveit thms 

2 ProofLite is freely available from http://research.nianet.org/~munoz/ProofLite. 
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reruns all the proofs in thins . pvs, writes the output into thms . out, and prints the following 
summary information: 

Processing thms. pvs. Writing output to file thms. out. 

Proof summary for theory thms 


thl proved - complete 

th2 proved - complete 

th3 proved - complete 

th4 proved - complete 

th3a proved - complete 

th4a proved - complete 

th_5_6 proved - complete 

th_6_7 proved - complete 

th_8 proved - complete 

th_9 proved - complete 


Theory totals: 10 formulas, 10 attempted, 10 succeeded (2.63 s) 

Grand Totals: 10 proofs, 10 attempted, 10 succeeded (2.63 s) 

The utility proveit supports several options, e.g, 

• The option -clean removes .pvscontext and other binary hies. This option is useful 
when the system has died abruptly and the context is left in an inconsistent state. 

• The option -importchain reruns the proofs of all imported theories as well. 

• The option -prooftraces outputs the proof traces, which are needed for regres- 
sion testing. Unfortunately, this option does not provide all the functionality of 
pvs-validate yet. This extension is planned for a future release. 

• The option -package loads a PVS strategy package such as Manip [16], Field [8], 
PVSio [5] or Interval [7]. For instance, if the proofs in thms. pvs use strategies defined 
in Field, the invocation has the form: 

°/ 0 proveit -package Field thms 

• The option -help prints the complete set of options supported by the utility. 

4.2 ProofLite Scripts 

ProofLite scripts are proof scripts written in specially formatted comments that reside in 
regular . pvs hies. The simplest type of ProofLite script has the form 

% I — <id> : PROOF <step> QED 

where <id> is the name of an existing formula and <step> is a proof command supported 
by the PVS strategy language [13]. 

For instance, the proof of thl can be written in the hie thms. pvs using the ProofLite 
script: 
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% I — thl : PROOF (grind) QED 


ProofLite scripts can extend to multiple lines. In this case, each line is preceded by the 
special comment For instance, the proof of lemma th2 can be written: 

7.1- th2 : PROOF 

7. 1 - (then 

7.1- (skeep) 

7.1 - (spread (case "a >= 0") 

7.1 - ((grind :theories "real_props") 

7.1 - (then (grind : theories "real_props") 

7.1 - (mult-ineq -1 -1 : signs (- -)) 

7.1- (assert))))) 

7.1 - QED 

Normally, ProofLite scripts are just comments to the PVS system. Indeed, unless ex- 
plicitly requested by the user, ProofLite scripts are not installed as proofs. The ProofLite 
utility prove it automatically installs proof scripts into their respective formulas when pro- 
cessing a .pvs hie. To prevent accidental overriding of proofs, by default, proveit does not 
install proof scripts in formulas that have an existing proof. To override existing proofs, 
the proveit option -force must be used. Installation of ProofLite scripts can also be done 
through the interactive PVS Ernacs interface as described in Section 4.3. 

Proof script sharing is supported by ProofLite. For instance, the following ProofLite 
script associates the same proof script to lemmas th3 and th4: 

7.1- th3 : PROOF 

7.1 - th4 : PROOF 
7» I - (grind) 

7.1 - QED 

The proof sharing mechanism is generalized to name-matching formulas, where the char- 
acter in the script identifier stands for an arbitrary sequence of one or more characters. 
In the following example, all formulas in thins. pvs whose names match the string “th*a”, 
e.g., th3a and th4a, share the same proof command: 

7.1 - th*a : PROOF (then (skeep) (grind-reals)) QED 

Proof scripts are not restricted to user-defined formulas. The following ProofLite script 
associates the same proof command to all Type Correctness Conditions (TCCs) in a theory: 

7.1- *_TCC* : PROOF <step> QED 

Name-matching lemmas can be used to create proof macros. In a ProofLite script 

7.1 - <id> : PROOF <step> QED, the proof command <step> may contain the special symbols 
$n, where n > 0. The symbol $0 refers to the name of the lemma that matches <id>. The 
symbol $n, where n > 1, refers to n-th matching string, from left to right, in the lemma’s 
name. Consider the ProofLite script 
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% I — th_*_* : PROOF 

% | — (then (skip-msg "Proving Lemma: $0") 

% I — (inst 1 "$1 + ($2 - $l)/2") 

% I — (grind)) 

% I - QED 

The string th_*_* matches the name th_5_6. Therefore, the symbols $0, $1, and $2 refer 
to th_5_6, 5, and 6, respectively. In this case, the proof command associated with lemma 

th_5_6 is 

(then (skip-msg "Proving Lemma: th_5_6") 

(inst 1 "5 + (6 - 5)/2") 

(grind)) 

Moreover, the string th_*_* matches the name th_6_7. Therefore, the proof command 
associated with lemma th_6_7 is 

(then (skip-msg "Proving Lemma: th_6_7") 

(inst 1 "6 + (7 - 6)/2") 

(grind)) 

Proof macros are particularly useful when PVS specifications are automatically generated 
and proof lemmas follow a particular naming convention. However, the parameters enabled 
by this mechanism are limited to substrings of valid identifiers. ProofLite supports a more 
general parameterization mechanism. Parametric ProofLite scripts have the form: 

7, 1 - <id> [el ; . . . ;en] : PROOF 
7o I — <step> 

7o I - QED 

In <step>, the symbol #n is substituted by e n . Consider the ProofLite script 

7o I - th_8 [2 ; 6] : PROOF 
7o I - th_9 [4 ; 5] : PROOF 

% | — (then (skip-msg "Proving Lemma: $0") 

7.1- (inst 1 "#1" "#2" ) 

7.1- (grind)) 

7.1- QED 

In this case, the proof command associated with lemma th_8 is 

(then (skip-msg "Proving Lemma: th_8") 

(inst 1 "2" "6") 

(grind)) 

Moreover, the proof command associated with lemma th_9 is 

(then (skip-msg "Proving Lemma: th_9") 

(inst 1 "4" "5") 

(grind)) 
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4.3 Proof Script Management Through the PVS Emacs Interface 

In general, a PVS package is loaded into the interactive PVS Emacs interface through the 
Emacs command M-x load-prelude-library, which will prompt the user for a package 
name, e.g., Proof Lite. This has to be done only the first time that the package is used in 
a working context or after the .pvscontext hie has been removed. 

Once ProofLite has been loaded into the PVS Emacs interface, a ProofLite script can 
be installed as the default proof of a formula by placing the cursor on the script and is- 
suing the Emacs command M-x install-proof lite-script. If the ProofLite is shared 
by several formulas, all proofs are simultaneously installed. However, this command does 
not install a proof in formulas that already have a default proof. The Emacs commands 
M-x install-proof lite-script ! forces the installation of a proof script regardless of the 
existence of a previous proof. 

All ProofLite scripts in theory can be installed for the first time through the Emacs 
command M-x install-proof lite-scripts-theory. Alternatively, the Emacs command 
M-x install-proof lite-scripts-theory ! installs all ProofLite scripts and overwrites any 
default proof. 

The default proof of a formula can be converted into a ProofLite script by placing the 
cursor on the formula and issuing the Emacs command M-x insert-proof lite-script. 
The script is automatically inserted in the . pvs hie after the formula. The Emacs command 
M-x display-proof lite-script prompts the user for a formula name and, then, puts the 
ProofLite script of the formula’s default proof in the Emacs buffer ProofLite. Afterward, 
the script can be modified and manually inserted anywhere in the . pvs hie. 

Key abbreviations for all these commands are listed in the following table. 


Emacs Command 

Key Abbreviation 

M-x install-proof lite-script 

C-c ip 

M-x install-proof lite-script ! 

C-c ! p 

M-x install-proof lite-scripts-theory 

C-c it 

M-x install-proof lite-scripts-theory ! 

C-c ! t 

M-x insert-proof lite-script 

C-c 2p 

M-x display-proof lite-script 

C-c dp 


5 APPLICATIONS 

ProofLite has been extensively and successfully used in verification projects at the National 
Institute of Aerospace and NASA Langley. 

Reference [2] presents a tool for mechanical verification of numerical bounds using interval 
arithmetic. The formal verihcation is performed in PVS. However, all the technical burden 
of proving properties in a proof assistant system is hidden from the user. In this case, a C++ 
modulc computes bounds of numerical expressions and, then, generates proof obligations, 
in the form of PVS formulas, along with ProofLite scripts that discharge the obligations. 
Formulas and proof scripts are written in a series of .pvs hies that are processed in batch 
mode via the command line utility prove it. The tool was used to formally check that a 
polynomial approximation, taken from a critical aeronautical application, is close to about 
one unit in the last place of the exact transcendental function, i.e., the relative error is 




bounded by 1.36 x 10-6. The C++ module generated about 30000 PVS lemmas, with their 
respective proof scripts, that were mechanically checked on a high performance cluster. 

Reference [6] reports on the formal verification of an operational concept for air traffic 
management in a self controlled airspace. The operational concept is modeled as a hybrid 
non-deterministic asynchronous state transition system. A tool, implemented in PVSio [5] 
and formally verified in PVS, explicitly computes the set of reachable states of the sys- 
tem. From this set, PVS lemmas, and their respective ProofLite scripts, are generated. 
All together, the lemmas guarantee that under nominal operations the minimum separation 
between two aircraft is higher than a given safety threshold. In total, 117 lemmas were 
generated and mechanically verified in batch mode via the ProofLite utility proveit. 

6 CONCLUSION 

ProofLite is a PVS package for batch proving and proof scripting that can be used by 
regular PVS users. The basic capabilities provided by the package are commonly found in 
comparable theorem provers such as Coq [14], HOL [4], and ACL2 [3]. 

The ProofLite scripting notation supports several forms of proof sharing and proof reuse. 
Modern theorem provers provide mechanisms to conservatively extend the proof search and 
automation power of their systems via user-defined strategies. Proof scripting provides a 
higher level of abstraction that is appropriate for certain kind of problems and domains. 

Future versions of ProofLite will fully support regression testing and will continue to 
explore new ways of sharing and reusing proofs. 
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